Once I get that upgrade to 36-hour days, I will tackle that. – Mychaeel
Legacy:Chip/Developer Journal
10/03/03
i'm fast approaching my first anniversary as a UT2003 modder. it's been an interesting journey so far: tentative explorations with UEd1, on to better-equipped expeditions using UEd3, navigating the dense undergrowth of Unreal Script, surviving an unsatisfactory detour into tc mod team territory, and finally to the here & now, with my first really fully-realized Unreal Script project ready for ... what???
do i just zip it up & find a web slot & hope it gets noticed? pimp the hell out of it on the forums? ask a few possibly amenable wiki/BUF denizens if they'd be willing to test/review/critique the work? the avenues for getting one's stuff out & about can seem a bit mysterious for those like myself new to the communities of computer gamers & modders.
my project, dubbed ModelViewer, is a development tool, an outgrowth of my experience learning to get a custom character model into UT2003. my first two maps gave me a pretty solid grounding in static mesh techniques and even vertex animation, but since i'm interested in Machinima as much as game-mapping, i wanted to learn about the possibilities for custom character development, i.e., skeletal meshes.
having built, boned, animated and skinned a biped creature in MayaPLE, i soon realized that once the character is alive and kicking (so to speak) in a map, the standard player view options are really not up to the task of close inspection of a model as it does its stuff. that, and the desire to explore modifications to the "camera" through which players view the Unreal universe, led me to produce ModelViewer.
from the draft "operating instructions" i've written for ModelViewer:
ModelViewer ... is designed to make in-engine viewing & evaluation of custom character models more versatile. ... ModelViewer gives UT2003 content creators a suite of player viewpoint controls analogous to those of an optical motion picture camera – pan, tilt, dolly, and zoom – so that custom character models can be more thoroughly examined "in-engine."
i realized that the anims i had lovingly tweaked in MayaPLE looked subtly different in UT2003 – motion in an abstract space is harder to evaluate than in an environment that bears at least some resemblance to the "real" world (whatever that is). but unlike MayaPLE or other modeling/animation apps, in UT2003 examination of player models from easily-changed viewpoints, and at various ranges, was a clumsy process at best, requiring (as far as i could tell), either spectating (with no pawn control) or using the limited BehindView and FreeCamera modes (views of the pawn from a relatively fixed distance or viewpoint).
so i scrounged through the classes for viewpoint functions and variables, looked into the possibility of using a mutator (not appropriate), and ended up writing a number of class extensions to gain greater control over how i could view my character in a map. once i had some new viewpoints, the faulty aspects of my character's animations were much easier to pinpoint, analyze, and subsequently eliminate.
but i found the process tedious after a while, since even after the principal view control functions had been debugged, there still remained the need to change various defaultproperties in my xPawn subclass to get the best "performance" from the model, and that meant re-compiling the entire package for every little change.
about this time i was thinking that this new viewpoint flexibility might be valuable to other modders as well, but i also know that editing and compiling Unreal Script is not everyone's cup o' java, even if it's just changing some default props. so, how to make it all a bit more user-friendly?
config files – easy to edit, relatively easy to access from Unreal Script – seemed a good approach, so i set about learning their ins & outs (inputs & outputs???). tests with a few config variables seemed to work well, so i set about setting up a config variable corresponding to nearly every default property in the xPawn class. a few of the value types required for the var declarations were puzzling, but digging through the 2225 source code usually unearthed a solution.
by now the concept of a full-blown dev tool was becoming much better defined – some custom classes implementing viewpoint controls, a map on which to stage the character model for examination, and a few "template" files into which users could plug their custom model info to make getting a character model into UT2003 a part of the ModelViewer system. with all the xPawn defaultproperties configurable by an easily edited .ini file, character developers could concentrate on character development rather than coding.
and it works. but it does need "other eyes" to scrutinize, both to provide feedback on the controls and to help insure the code isn't hiding some flaws just waiting to do gotchas on unsuspecting users. i don't have the depth in Unreal Scripting to feel really confident in that regard. but as i mentioned above, the protocols in the mod community for asking favors of other modders (e.g., beta evaluations) are, for me, somewhat impenetrable. does one just up & ask?
10/30/03
I've been tweaking ModelViewer over the last month, getting the documentation finalized, and it's ready for beta trials. Character modelers and animators should find it useful. I'm also getting some feedback on my UT2003 map CTF-NeonArena, mainly regarding gameplay characteristics, before I put it on a public download site. Interested Wikians can contact me – always good to have another perspective.
One aspect of the CTF map I found troublesome was getting the movers to work in netplay as they do in standalone. Using a LAN setup, I found that the "hatch" movers on the two flying vehicles don't stay attached to the rest of the vehicle, which is also a set of movers, one of which provides the AttachTag for the others. This is all necessary because the vehicles fly into "parking" positions in the standalone opening cinematic, then drift up and down slowly at station-keeping. The hatches are TriggerOpenTimed and team-specific, and in the cinematic & standalone work great, but in netplay they stay stationary while the rest of the vehicle does its drifting thing. UG-LEE.
The map detects NetMode != NM_Standalone & bypasses the cinematic, just as it does for certain conditions in standalone play, but there must be some replication issues involving movers attached to movers that I wasn't able to trace. The problem seems to only affect attached movers that also have keyframes (the hatches open & close), because the attached movers that form the rest of the vehicle (no keyframes) didn't show the difficulty.
A few dozen attempted but unsuccessful fixes later I just decided to kill the vehicle drift for netplay; it's only a cosmetic thing, and the hatches look right & still open properly, but I dislike having to compromise.
Note to self: Must learn more about replication, so as to plan maps better from the get-go.
11/03/03 LI hodie. Tempus fugit cum perfrui vita.
(apologies to scholars of linguas caput)
11/12/03
working on a tute for the wiki re: skinning. why izzit that a process that seems rather straightforward and efficient when put into practice seems complex and clutzy when put into words?
the first example's done, but i have to model up a character next, for the "advanced" skinning section.
also doing some small-scale beta testing of MilkShape 1.7's psa/psk exports, using a rudimentary custom skeleton & meshes. results are promising but there are still some issues with the final result in UEd.
